This is just an update to #311, nothing new. /cc @josh

Add compile_with_map to the coffee script gem.

No new calls need to be added there. We can already pass options to compile.

The one think that is blocking me from progress here is the pipeline processor api. I'm working on redoing it for 3.0 first. Once thats out that will allow processors to pass extra data between each other like source maps.

The reason for compile_with_map in uglify was that it needs to return two strings. I guess we could make the method do that if you pass the right options, but it's very odd.

Or we could do it like coffee-rails-source-maps and just write to a temporary file.

The reason for compile_with_map in uglify was that it needs to return two strings. I guess we could make the method do that if you pass the right options, but it's very odd.

It doesn't really matter, we can invoke whatever api the processor exposes here.

https://github.com/sstephenson/sprockets/blob/master/lib/sprockets/coffee_script_template.rb#L9

There isn't even a unified api right now, so I'm expecting everyone to expose different source map apis. Coffee, Uglifier, Sass, YUI, ClosureCompiler are all going to do different things. Our wrappers will normalize them.

I worked on https://github.com/maccman/sourcemap which is a useful Ruby structure around the json object. Thats what I plan to hand off between processors.

Or we could do it like coffee-rails-source-maps and just write to a temporary file.

Nothing should be written to disk when templates are compiled. It should be a "pure functional" transformation.

On Fri, Feb 14, 2014 at 11:30 AM, Joshua Peek [email protected]:

The reason for compile_with_map in uglify was that it needs to return two
strings. I guess we could make the method do that if you pass the right
options, but it's very odd.

It doesn't really matter, we can invoke whatever api the processor exposes
here.

https://github.com/sstephenson/sprockets/blob/master/lib/sprockets/coffee_script_template.rb#L9

Yeah, at the moment that API isn't exposed at all (or at least not
documented at all); so we'll need to fix that gem first.

I worked on https://github.com/maccman/sourcemap which is a useful Ruby

structure around the json object. Thats what I plan to hand off between
processors.

I know, you copied my code from
https://github.com/ConradIrwin/ruby-source_map :). I had a slight about how
uglify will treat the low-fidelity (per-line) source maps we generate; will
it set the column number to 0 for every token on the line, or will it
interpolate correctly; but that's easy to test.

Yeah, at the moment that API isn't exposed at all (or at least not
documented at all); so we'll need to fix that gem first.

You can just pass whatever options to CoffeeScript.compile.

https://github.com/josh/ruby-coffee-script/blob/master/lib/coffee_script.rb#L47

Though, I'm thinking having a separate compile_with_map would be nice because we could feature detect if the gem supports source maps from sprockets. Backwards compat is a little tricky with that gem because it needs to support every version of coffee-script-source published even when source maps didn't exist.

Do you need any help with source map support? This task is really important to me.

This is taking forever...#311 started 2 years ago...ugh. Really want to see this finally land.

Grunt already has source map support. Even Mincer (Sprockets port to node.js). So I think this feature is very important, because source map helps with Sass and CoffeeScript debug.

I too offer to help on source maps if you need it.

+1 - happy to review / test / etc.